NAT = Network Address Translator (device) or Network Address Translation (concept) depending on context.
PAT = Port Address Translator (device) or Port Address Translation (concept) depending on context
This problem is very common when either end (client or server) is behind a NAT/PAT boundary that does not support the PPTP+GRE protocol -- or does not support it well.
In the realm of PPTP, TCP/1723 is a simple control channel whose sole purpose is to bring up a Microsoft specific secondary GRE (IP/47) tunnel. This GRE tunnel contains encapsulated PPP frames and is used for negotiating authentication, encryption, and passing actual data.
Not all NATs (firewalls, routers, appliances) support passing the secondary GRE tunnel to clients/servers. The PPTP VPN client will appear to connect, get to a "Verifying Username and Password" message and hang there. The "Verifying Username and Password" stage requires the GRE tunnel to be functional.
Some NATs/PATs may support a single PPTP+GRE for a single user behind the NAT/PAT, but a second PPTP+GRE from either the same user or a different user behind the NAT/PAT can fail. I have seen many kinds of spectacular failures with PPTP+GRE through NAT/PAT with both consumer, business, and enterprise grade NATs/PATs
In your specific case -- if other users can connect to your RRAS fine using PPTP+GRE, but this single user cannot -- it is likely the NAT/PAT boundary on that user's network.
Be prepared to spend a lot of time diagnosing this problem if this particular user has substandard Internet and edge hardware -- especially if it is from a provider performing Carrier Grade NAT (CGN).
If you can gain access to the user's PC and run Wireshark on their PC while trying to connect and look for GRE datagrams both to and from the RRAS server. If the GRE tunnel is failing you will likely see a GRE datagram destined for the RRAS server public IP, but not see a return GRE datagram from the RRAS server public IP.
If this is the case the concern is upstream from the PC. Look at all upstream NATs/PATs to ensure they support PPTP+GRE fixup/passthrough/inspection or whatever that vendor calls it. Know that some vendors, despite "support" for PPTP+GRE, only support it in limited manners -- as described earlier. Cisco ASA's and PIX's have had rather excellent support for PPTP+GRE fixup/inspection for quite a while -- usually not enabled by default.
Running PPTP, L2TP, and IPsec VPN's through NAT/PAT are all rather problematic unless care is taken to overcome the NAT/PAT. About the only VPN tech that can penetrate NAT/PAT rather easily is SSL/TLS based VPN's -- in my experience.